A variety of networks are used today. Computer networks include local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), intranets, the Internet, and other types of networks. Communication networks include those for conventional telephone service, cellular networks of different varieties, paging services, and others. Networks are used for many purposes, including to communicate, to access data, and to execute transactions. It is often necessary, for security and other reasons, to confirm and/or verify the identity of a user before permitting access to data or a transaction to occur on the network. The user may be an individual, although it is also common for small businesses to access websites at which they need to have their identity verified.
“Verification” is the process of confirming the identity of a person, entity, and/or device at the other end of a channel. It is important in many industries, for example financial service providers (FSPs), to establish whether or not the user on the other end is who they claim to be. FSPs (banking, securities, brokerage, and insurance industries) have traditionally relied on face-to-face communications, but with the advent of identity management, tokens, bio-metrics, and digital signature technology, face-to-face communication as a manner of doing business is slowly becoming the exception rather than the norm. However, the obstacle of distance as it relates to electronic interaction will be overcome only when a means to verify individuals, entities, and businesses is established.
Establishing verification at the beginning of an online process is a particularly important step and has become one of the most important trust issues for online businesses. Even in the most robust organizations, verification is a dynamic and evolving business risk because fraud continues to threaten online transactions and erode consumer confidence in online services, especially financial services. Beyond simple phishing scams, new threats such as man-in-the-middle attacks, bots, keystroke logging, and remote administrator tools are appearing. While some of these threats can be minimized or eliminated with common sense, others are stealth, sophisticated, and undetectable. The Federal Trade Commission estimates that millions of Americans have had their personal information pilfered and misused in some way or another every year, costing consumers and businesses billions annually. Furthermore, some projections estimate that online U.S. commerce growth will be lowered materially in coming years, as service providers struggle to find the right verification solutions that do not inconvenience consumers and are cost-effective to implement.
Another driver of verification is the recently mandated Federal Financial Institutions Examination Council (FFIEC) guidelines for financial institutions. While they are not regulations, the FFIEC expects all FSPs to comply with the guidance by the end of 2006. It mandates that FSPs have an effective security program that prevents unauthorized access and only permits authorized users to access systems and data. With the new guidelines, FSPs have been forced to rethink their online verification and authentication approaches. They need solutions that apply across their entire organization. They need the ability to define requirements that are applicable for the enterprise as a whole. They need solutions that will help them become compliant and meet their business needs so that they can fully use electronic channels and grow their business and revenue.
Verifying new users is different from authenticating existing users. Confirming the identity of a user can be a key aspect to improving overall security, not only in operations which require authentication of users, but also where verification is required. As a general matter, authentication relates more to confirming the identity of an established user and/or a user with an existing account, while verification relates more to confirming identity of a user who or which has not been established and/or who or which does not have an existing account or relationship. Although there may be, to some extent, an overlap in definition of verification and authentication, or in the status of a user whose identity needs to be confirmed, it is also generally true that to date, security, hardware, software, and token companies have focused on providing authentication services more than verification services.
There are some solutions in the marketplace that offer verification, but they are primarily industry-specific. For example, solutions for FSPs may require the user to make an account-to-account funds transfer. Another example is Equifax eID solutions, which requires the end user to have a thorough understanding of his/her financial and personal information. While both of these options may meet the needs of perspective target markets, they do not offer a solution that can always be used by all markets. Accordingly, additional verification/authentication engines with more sophisticated features and options are needed.
As a practical matter, in the architecture or design of a workable verification and/or authentication solution, it is preferable to recognize that once a user has initially been verified, when he or she returns to a website (e.g., to conduct additional business, access additional applications, platforms, or conduct transactions), his or her identity will need to be authenticated or re-confirmed every time he/she returns, or some equivalent security mechanism will need to be employed. Such repeat visits are different in some ways from verifying a new user. With respect to computer network authentication, one approach is user-specific passwords. Passwords provide some level of protection, but they are not fail-safe. Passwords can be vulnerable because users often share them or they can be easy to guess. Even if kept private, someone who wants to obtain a password badly enough often can—using random generators, keyboard monitors, or other techniques. Moreover, when dealing with unknown users such as people who want to conduct an electronic transaction over the Internet and who have not yet been verified, ad hoc passwords are not practical.
Various non-password schemes exist that perform some level of authentication and/or verification before authorizing transactions or permitting access to data. These systems generally require a user to provide a sampling of basic identification information such as name, date of birth, social security number, address, telephone number, and/or driver's license information. This sort of information, sometimes known as “wallet-type information,” is compared to known data, such as a credit file, to determine how well the user's input matches that source.
For various reasons, one-level authentication schemes are not completely reliable. In some instances, a user who provides accurate identification information may not be authenticated. This may occur, for example, because the user enters a nickname rather than a proper name, and the authentication process does not check for a nickname or other variation. As a result, a user who should be entitled to access information or perform a transaction cannot do so. Other inconsistencies may trigger a false negative, and often the false negative (perhaps after a set number of tries) will terminate the transaction without further processing or corrective querying. In other instances, a user who supplies fraudulent information may be authenticated. This may occur when lost or stolen wallet-type information is entered by an unauthorized user. Other situations may also lead to a false positive result. Both false positives and false negatives are undesirable.
Some attempts to address these problems have included verifying consumers, via static data, for retail applications. An example of this approach is when a consumer applies for a store credit card on-site and is connected on the phone with a credit reporting agency to answer a series of questions that are in the consumer's credit history file for an automatic approval or denial of store credit. Other attempts have included providing a first level authentication that may include queries related to wallet-type information, and if those questions are answered correctly, it may then proceed to a second level authentication that includes questions related to non-wallet type information such as mortgage account information, lender, merchant account information, and so forth. Once the end user attempting to access a system has answered an appropriate number of questions correctly, access may be granted or denied. An example of such systems and processes is described in U.S. Pat. Nos. 6,857,073 and 6,263,447, incorporated herein by reference. Such systems and processes can draw from one or more types of databases, such as credit related databases, postal service databases, telecommunication databases, and other types of data.
Other attempts have included using biometric data, for example a fingerprint captured in digital or analog form, a retinal or iris scan, finger or hand geometry matches, or handwriting recognition or voice recognition. These solutions may be useful in some instances, but they may not always be practical due to various technology constraints.
An additional problem experienced by some financial institutions is verifying the identity of small businesses. Small businesses may have shorter life spans than large business, which can make it more difficult for systems to accumulate, store, and access data about the credit history of the business. Small businesses may also not have sufficient assets on which a financial institution will extend credit. Often, the credit may be extended to the small business owner(s) as a personal loan. Although that loan is effectively part of the financial landscape of the small business, the loan would not be reflected as a part of the small business credit history file. As such, lenders and other financial institutions may have more difficulty when attempting to verify the identity of a small business because the owner(s) or principal(s) may also need to be verified and their credit history and other data checked, etc. Lending to this difficulty could be an instance in which multiple banks are involved.
For example, a small business may bank with Bank 1; one owner of the small business may obtain with Bank 2 a personal loan to infuse into the business; and a second owner may obtain a similar personal loan with Bank 3. Bank 1 may wish to verify the business, but the business may not have a credit history with which Bank 1 can easily cross-check and verify data. Accordingly, it is desirable to provide a verification/authentication engine that call pull data from multiple sources, in this example, from Banks 2 and 3 (to the extent that they share publicly available information on websites such as the Small Business Financial Exchange). Such systems are disclosed in U.S. Ser. No. 10/021,468, filed on Oct. 29, 2001, titled “System and Method for Facilitating Receprocative Small Business Financial Information Exchange,” which is incorporated herein by this reference.
It is also desirable to provide an entity (in this case, Bank 1) with the option to change, “dial,” or assign at least different risk or verification levels and sources of data required for authentication or verification of users who seek to conduct online activities. For example, if the small business would like to obtain a loan of $50,000, online activities to conduct such a transaction might require one level of verification and/or authentication which is based on presentation and scoring of questions from a first set of data or databases. However, a loan of ten million dollars could require a different and higher level of verification and/or authentication based on presentation and scoring of questions from another set of data or databases, in order, among other things, to apply more stringent, rigorous and/or more difficult authentication or verification scrutiny.
Because technology is continually changing, and the need for adequate security is crucial, a dynamic verification/authentication engine that meets specific businesses' needs and regulatory compliance guidelines is necessary. It is also necessary to provide a system that enables businesses to establish their own risk assessments according to their internal practices and principles. Accordingly, there are needs for further verification and authentication systems and methods that can be used across industries for multiple purposes.